home *** CD-ROM | disk | FTP | other *** search
- Subject: Re: Scope of an APP_DEFS file
- Date: Mon, 01 Aug 1994 11:14:46 +1000
- From: Warwick Allison <warwick@cs.uq.oz.au>
- Precedence: bulk
-
- Rick Flashman wrote:
- >On Fri, 29 Jul 1994 d.oakley.kid0111@oasis.icl.co.uk wrote:
- >
- >> The advantage of not using dialogs is speed
- >
- >That must depend on code speed. I can't see any noticeable difference in
- >opening a windowed dialog vs. a regular dialog under Geneva (that's on an
- >8mhz 68000).
-
- The advantage comes if the dialog routine uses a temporary raster storage of
- the screen under the dialog rather form_dial. This means no redraw is needed
- (just replace the saved area). LTMF provides this, as do some GEM libraries
- (eg. GEM++ saves the area under dialogs, if it can get the RAM).
-
-
- >> programs will not use their own preference files: Am I right or wrong?
- >
- >I disagree. Programs like Geneva and NeoDesk keep a substancial amount of
- >additional information (everything from a program_flag list for Geneva to
- >dialog_positions for NeoDesk). I doubt you would want an APP_DEFS file
- >overwhelmed by all that application specific stuff.
-
- Some bulk preferences may perhaps be left out, but for most things, it
- shouldn't be a big deal. While reading the app_defs file, an application
- can instantly skip any lines that don't start with their name (app-specific
- preference) or a "*" (global preference), so the cost is low. Perhaps we
- can think of some recommendation, such as "If your app has more than 100
- app-specific options, consider moving some of the bulk options to a separate
- file. That file should, however, be pointed to from the app_defs file,
- so as to enable all the other advantages of app_defs (such as multi-user)".
-
- --
- Warwick
-